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Description 

Field of the Invention 

[0001] The present invention is directed to computer 
systems, and more particularly to the monitoring of the 
performance of one or more application programs being 
executed on a computer system. 

Background of the Invention 

[0002] As computer systems continue to grow in size, 
and the capabilities available to end users via such sys- 
tems continue to expand, there is an ever-increasing de- 
mand upon available resources. This is particularly true 
in the case of computer networks, where a common re- 
source may be shared by a number of client computers. 
In such a situation, bottlenecks can occur during the ex- 
ecution of application programs that are being run by 
users on individual clients of the network. The ability to 
recognize and prevent such bottlenecks from occurring 
during the execution of application programs has a di- 
rect impact on the productivity of the users of the com- 
puter system. To this end, therefore, it is desirable to 
monitor the response time of an application program 
during execution, to identify potential bottlenecks. By 
doing so, available resources can be reallocated as nec- 
essary to ensure optimum performance. 
[0003] In general, one indication of application per- 
formance is obtained by measuring the amount of time 
that is required to respond to a particular request made 
by or to an application program. To do so, it is therefore 
necessary to record the times at which the request is 
generated, and the response is returned. By measuring 
the latency between the recorded times, a metric is ob- 
tained that provides a good indicator of the application's 
performance. Depending upon the amount of informa- 
tion that is desired, different amounts of monitoring cri- 
teria can be established. For example, if a measure of 
gross latency is sufficientto monitor performance, it may 
only be necessary to record the time at which the re- 
quest is initially generated and the time at which the ul- 
timate response is returned. Alternatively, if more infor- 
mation is desired, a time can be recorded for each indi- 
vidual task that is carried out in responding to the re- 
quest, such as opening windows, performing calcula- 
tions, etc. 

[0004] In the past, the recording of the time at which 
various events occur during the execution of an appli- 
cation program was accomplished by incorporating ap- 
plication programming interfaces (APIs) into the pro- 
gram whose performance was to be monitored. In es- 
sence, these programming interfaces provide a form of 
instrumentation that permit individual events in the ex- 
ecution of an application to be identified, so that the time 
of their occurrence can be recorded. One particular ad- 
vantage of this approach is the fact that any amount of 
desired detail, at any given level of operation of the pro- 



gram, can be obtained. 

[0005] However, there are various limitations associ- 
ated with this "instrumented" approach. One of these is 
the fact that it is highly labor intensive, since it requires 

5 the program to be rewritten to incorporate the APIs. To 
do so, of course, requires access to the source code for 
the program. As a result, off-the-shelf programs that are 
typically sold in "shrink-wrapped" form cannot be adapt- 
ed by the user to monitor their performance. 

10 [0006] Recently, a standard set of AP Is has been pro- 
posed to provide greater uniformity in performance 
monitoring. See "Application Response Measurement 
API Guide", May 1996. While these standard APIs can 
be readily incorporated into newly developed programs, 

15 they cannot be used with pre-existing programs unless 
the programs are rewritten to incorporate them. Again, 
therefore, significant effort must be expended to be able 
to monitor such programs. 

[0007] A different, but related, approach is disclosed 

20 in U.S. Patent No. 5,485,574. In the system of this pat- 
ent, a facility is provided in the kernel of the computer's 
operating system to count instructions or calls to sec- 
tions of program code. While this approach avoids the 
need to incorporate APIs into individual application pro- 

25 grams, it still requires that a program, in this case the 
kernel of the computer's operating system, be modified 
to provide the necessary instrumentation. In addition, 
results are obtained at the kernel level of the operating 
system, rather than at the application or user level. 

30 [0008] As an alternative to the instrumented approach 
that requires customization of an individual program, an- 
other techniquefor monitoring the performance of a sys- 
tem relies upon network-based communications. Typi- 
cally, communications between an application program 

35 running on a client station and a network server are 
transmitted via individual data packets. All of the pack- 
ets pertaining to a given application program are trans- 
mitted through a logical port associated with the server. 
In the network-based approach to monitoring, all pack- 

40 ets which pass through a given port are opened, and 
examined, to determine the types of actions to which 
they pertain. If a packet contains data relating to a task 
of interest, the time at which that packet passes through 
the port is recorded. The advantage of this approach is 

45 that it does not require any modification of the applica- 
tion program, and theoretically is applicable to all avail- 
able programs. However, the results provided by this ap- 
proach are not completely accurate. In particular, the ex- 
amination of the data packets takes place along the 

50 communication path between the client station and the 
network server. As such, the times which are recorded 
in association with each packet only reflect the instance 
at which the packet passes through the designated port. 
They do not include additional processing time that may 

55 be encountered by the packet after it passes through 
the port but before the final result is delivered to the re- 
questing application. As another consideration, the ex- 
amination of the packets is typically carried out by a ma- 
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chine that is separate from the client station, and hence 
this approach presents increased hardware expenses. 
Furthermore, in order to examine the individual packets, 
the network interface card must operate in a promiscu- 
ous mode to permit the port traffic to be examined. Since 5 
this mode of operation permits external entities to ac- 
cess the packets, security is compromised. 
[0009] It is desirable, therefore, to provide a non-in- 
strumented monitor which does not need to be incorpo- 
rated into specific programs, and thereby permits the 
performance of any program to be monitored without 
modification thereof. Further in this regard, it is desirable 
to provide such a system which is client-based, so that 
it provides a true measure of the response time associ- 
ated with a given task. 

Summary of the Invention 

[0010] In accordance with the present invention, as 
defined in detail in the appended independent claims, a 
system for monitoring the response times of application 
programs detects events of interest by examining com- 
munications between an application program and the 
computer's operating system. A configuration module 
permits a user to identify specific events that occur dur- 
ing the operation of application programs, by presenting 
a sequence of messages that are passed between the 
application programs and the operating system. Prefer- 
ably, the messages are described by means of a high- 
level language which employs readily comprehensible 
terms that avoid the need for a detailed understanding 
of the application program itself. The user can then se- 
lect specific events of interest to be recorded for moni- 
toring purposes. Thereafter, as the application pro- 
grams execute, the events of interest are recorded. The 
latency between recorded events represents the re- 
sponse times of the application programs. These re- 
sponse times can be stored in a file for the generation 
of a report pertaining to application performance. 
[0011] Further features of the invention, and the ad- 
vantages offered thereby, are described hereinafter with 
reference to an embodiment of the invention illustrated 
in the accompanying drawings. 

Brief Description of the Drawings 

[0012] 

Figure 1 is a block diagram of a networked compu- 
ter system in which the present invention can be im- 
plemented; 

Figure 2 is a flow chart of the steps that are carried 
out in the servicing of a request; 
Figure 3 is a schematic block diagram depicting the 
exchange of messages between an operating sys- 
tem and client applications; 
Figure 4 is a block diagram of the architecture of an 
application monitoring system; 



Figure 5 is a functional block diagram of the opera- 
tion of the configuration manager module; and 
Figures 6-8 illustrate display panels that are pre- 
sented to the user during the definition of a trans- 
action to be monitored. 

Detailed Description 

[001 3] To facilitate an understanding of the present in- 
vention, it is described hereinafter with reference to a 
particular embodiment that is implemented in the con- 
text of a computer network that is designed to operate 
with client applications that run on the Windows® oper- 
ating system. It will be appreciated, however, that the 
practical applications of the invention are not limited to 
this particular implementation. Rather, the principles 
which underline the invention are applicable to stand- 
alone computers as well as computer networks, and can 
be used with a variety of different operating systems. 
[001 4] A typical network of a type in which the present 
invention might be employed is illustrated in block dia- 
gram form in Figure 1 . The network includes a central 
server 1 0 that services requests promulgated by various 
client application programs 12 running on individual 
nodes 14 of the network. For example, the server may 
include a database 16 which can be accessed by one 
or more of the client applications. A typical request from 
the client applications may be to retrieve certain data 
from the database, and return it to the requesting appli- 
cation, so that it can be displayed to the user at a given 
node in a desirable format. 

[0015] As an example, a user at one of the network 
nodes may issue a command to retrieve all records from 
the database which match a given search criterion, and 
sort the retrieved records in date order. The steps that 
are involved in the servicing of this request are illustrat- 
ed in Figure 2. Referring thereto, the request is initiated 
when the user generates the instruction to perform the 
scan, for example by clicking upon an "OK" button in a 
window, or the like. The command associated with the 
clicking of this button, including the search parameters 
established by the user, are transmitted from the user's 
node to the network server. At the server, the database 
is scanned, and the records matching the search criteria 
are retrieved. Thereafter, the appropriate calculations 
are performed on the retrieved records, to sort them in 
the requested order. Once the sorting has been com- 
pleted, the results are returned to the client application 
at the requesting node. At the node, a suitable window 
is opened and the results are displayed in the window. 
The total time between the initial generation of the re- 
quest and the ultimate display of the results that are re- 
sponsive to that request is a measure of the latency as- 
sociated with the servicing of the request. By measuring 
the length of such latencies, it is possible to obtain a 
metric of the application response time. 
[0016] In accordance with the present invention, this 
latency is measured by detecting preselected events 
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that are associated with actions of interest. Typically, op- 
erating systems rely upon the interchange of information 
between the client application and the operating system 
itself. For example, when the user moves a cursor to a 
specific position on a display screen and clicks a mouse 
button, the operating system must inform the client ap- 
plication of the location of the cursor and the fact that 
the mouse button was clicked at this location. Depend- 
ing upon the command associated with the clicking of 
the button, the client application may, in turn, inform the 
operating system of an action to be carried out, e.g., 
transmit a request to the network server. The present 
invention monitors application response times by ob- 
serving these types of communications between an ap- 
plication program and the computer's operating system. 
[001 7] In the Windows operating system, for example, 
the exchange of information between the operating sys- 
tem and a client application is carried out by means of 
"messages." Referring to Figure 3, when an application 
program is running on a computer, the computer's op- 
erating system creates a message queue in the memory 
space which is allocated to that program. In the example 
of Figure 3, there are two application programs currently 
being executed, and hence two message queues have 
been created in their respective memory spaces. When- 
ever there is information to be passed to an application 
program, for instance keystrokes entered by a user or 
a mouse button click, the operating system places this 
information in the message queue for that application. 
The application program periodically sends a command 
to the operating system to get its messages. In re- 
sponse, the operating system passes the contents of the 
message queue to the application. Conversely when- 
ever the application program has information to pass to 
the operating system, e.g., data to be transmitted to the 
network server 10, the application program may send a 
command to the operating system via a message. In re- 
sponse, the operating system reads the message, de- 
termines the action to be taken, and proceeds accord- 
ingly. 

[0018] In accordance with the present invention, the 
application response time is monitored by examining the 
contents of the communications between the operating 
system and an application program, to detect certain 
events of interest. The latency between the selected 
events is recorded as the measure of response times. 
[0019] The observance of communications to monitor 
response times is carried out by a program known as 
an applications agent. Referring again to Figure 1, an 
applications agent 18 might reside on each node 14 of 
the network having a client application 12 whose re- 
sponse times are to be monitored. The applications 
agent is external to the application program itself that is 
to be monitored, and runs in the background in a manner 
that is transparent to the user. The architecture of the 
overall application monitoring system is illustrated in 
Figure 4. The main components of the monitoring sys- 
tem are the application agent 18, a central dispatcher 



28 and a configuration manager 30. The configuration 
manager 30 enables the user to define the events that 
are to be monitored during the execution of an applica- 
tion program. For this purpose, the configuration man- 

s ager includes various display panels 32, by which the 
user establishes the parameters for the monitoring of an 
application. The operation of the configuration manager 
will be described with reference to a functional block di- 
agram shown in Figure 5 and exemplary display panels 

10 illustrated in Figures 6-8. 

[0020] In general, the configuration manager oper- 
ates by monitoring an application program while it per- 
forms a task of interest, recording events that occur in 
connection with the task, and enabling the user to iden- 

15 tify selected events as the measuring criteria for appli- 
cation response times. To define a transaction to be 
monitored, the user first launches the application, or ap- 
plications, to be monitored, if they are not already run- 
ning on the computer. The user then issues appropriate 

20 commands, for example through one or more interface 
windows (not shown) to indicate that a transaction is to 
be defined. 

[0021 ] In response to such a command, a Transaction 
Recording dialog box can be displayed, for example of 

25 the type illustrated in Figure 6. This dialog box provides 
the user with two accessible controls for recording mes- 
sages relating to a transaction, namely "start" and 
"stop". As an alternative to a dialog box, it is also pos- 
sible to employ commands from a drop-down menu, or 

30 predefined keystrokes. When the applications running 
on the computer reach a point at which the user desires 
to define a task to be monitored, the user starts trans- 
action recording, by clicking upon the "Start" button in 
the dialog box, or pressing an appropriate key on the 

35 computer's keyboard. This action activates a message 
recording function within the configuration manager 30. 
Thereafter, the user can perform any tasks that are nec- 
essary to the operation to be monitored. For example, 
if the user is interested in the latency associated with 

40 the servicing of a request to retrieve data from a data- 
base, the user generates the necessary commands to 
cause an application to carry out this function. Once the 
transaction has been performed, the "Stop" button, or 
an appropriate keyboard key, is pressed to terminate the 

^5 recording function. 

[0022] Referring again to Figure 4, as the transaction 
is being recorded, all of the messages that are ex- 
changed between the computer's operating system and 
currently running application programs are detected and 

50 stored by the central dispatcher 28. Once the recording 
of the transaction has been terminated, all of the stored 
messages are provided to the configuration manager. 
In response, the configuration manager displays a 
Transaction Macro dialog box 38, as schematically illus- 

55 trated in Figure 5. A more detailed example of such a 
dialog box is shown in Figure 7. This dialog box presents 
to the user a sequential display of each message that 
was generated during the recorded portion of the trans- 
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action. For ease of understanding, the particular exam- 
ple shown in Figure 7 illustrates messages that are ex- 
changed between the operating system and a single ap- 
plication program. In practice, however, multiple appli- 
cations may be running on the computer concurrently. 5 
In such a case, the dialog window 38 lists all of the var- 
ious messages that are exchanged between the oper- 
ating system and the executing programs during the 
transaction recording period. 

[0023] From the listing in the dialog box, the user can 
select specific messages that identify the beginning and 
end of the transaction that is to be monitored. This is 
accomplished in the illustrated Transaction Macro dia- 
log box by clicking a mouse button while the cursor is 
positioned in a column labelled "Begin/End", adjacent 
the messages of interest. In the specific example of Fig- 
ure 7, the user has selected the clicking of a "Scan" but- 
ton as the beginning of a marked transaction, and the 
subsequent clicking of an "OK" button to end the trans- 
action. Of course, other techniques for identifying the 
beginning and ending statements for a transaction can 
be employed as well. 

[0024] In the example of Figure 7, a single event is 
displayed for the action which initiates the scanning of 
the database to retrieve certain results. Once the results 
are returned to the client application, a window is creat- 
ed and the results are displayed within the window. Sub- 
sequently, the user clicks an "OK" button to remove the 
display of those results. Although only three events are 
depicted in the dialog box of Figure 7 for this activity, in 
practice numerous messages might be exchanged be- 
tween the operating system and the application program 
to perform the required task. Furthermore, the actual 
terms employed in those messages may not be readily 
understandable to the average user. To this end, there- 
fore, the central dispatcher 28 preferably employs a 
high-level language, such as a macro language 36, to 
translate the specific content of the messages ex- 
changed between the operating system and the appli- 
cation programs into terms that can be readily under- 
stood by the average user. Figure 7 illustrates examples 
of such terms, which can be used to identify when a win- 
dow is created or destroyed, and when a user clicks on 
a button within a window. Each term has associated pa- 
rameters that identify the function associated with that 
term. For example, the "WindowCreated" term is fol- 
lowed by three parameters which identify the name of 
the application with which the window is associated, the 
title of the window, and the chain of parent windows with- 
in which the window being created is contained. To ac- 
tually create a window, or to exchange information re- 
lating to the clicking of a button, several messages may 
pass between the application program and the operat- 
ing system. Preferably, the macro language 36 encap- 
sulates several of these messages, and/or events, into 
a single term that is displayed in the transaction macro 
dialog window of Figure 7. 

[0025] As alternatives, it is possible to employ other 



8 

types of high-level languages to perform this function. 
For example, a script language, a programming lan- 
guage, or a code generator could be employed to trans- 
late low-level messages exchanged between the appli- 
cations programs and the operating system into higher 
level terms that are more readily understandable to the 
user. 

[0026] Once the user has selected the beginning and 
ending message statements that mark a transaction to 
be recorded, that particular transaction can be given a 
unique name, for subsequent use. At this point, the def- 
inition of the transaction to be monitored is complete. 
Once the transaction has been defined, it can be distrib- 
uted to agents 1 8 on the nodes in the computer system 
where the transaction is to be monitored, as depicted in 
Figure 5. To this end, the configuration manager 30 pref- 
erably provides the user with a view of all agents running 
on the network, so that the defined transaction can be 
distributed to selected agents. 

[0027] The primary function of a defined transaction 
is to measure the time that elapses between the begin- 
ning and ending events identified by the user. Referring 
again to Figure 4, when a transaction is to be monitored, 
the beginning and ending messages are supplied from 
the agent 18 to the central dispatcher 28. The dispatcher 
initiates a message watch function 34 which monitors 
each message that appears in the message queue for 
an application of interest. In the Windows operating sys- 
tem, for example, the contents of a message queue can 
be observed without affecting the message by means 
of a suitable message hook, which examines each mes- 
sage before it is passed to the application. Whenever a 
designated beginning or ending message appears in the 
queue, the central dispatcher informs the agent 18, 
which records the time at which the message appeared. 
For each recorded pair of start and stop times, the agent 
1 8 computes the latency between the detected events, 
or messages. The calculated latencies are then stored 
in a file, for the subsequent generation of a report. 
[0028] In the preceding example, only one pair of be- 
ginning and ending messages was identified to monitor 
response times. To obtain a greater amount of detail 
about the operation of a program, it may be desirable to 
establish nested sets of start and stop times. For exam- 
ple, within the latency associated with the performance 
of a general task, the user may wish to also measure 
the latencies of more specific tasks that are carried out 
in the implementation of the general task. In a preferred 
embodiment of the invention, therefore, the user can 
designate multiple start and stop times for a given trans- 
action to be monitored. During the transaction, the la- 
tencies associated with each pair of associated start and 
stop times are calculated and stored, for subsequent re- 
porting purposes. 

[0029] In addition to measuring the latency associat- 
ed with the performance of tasks, the agent 1 8 permits 
other types of network monitoring functions to be carried 
out. To this end, the user can establish a policy that can 
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be applied to a defined transaction. In essence, a policy 
comprises a saved definition of the agents which are to 
monitor a defined transaction, additional metrics that 
can be measured in addition to the defined latency pe- 
riod, and specific times at which the monitoring opera- 
tion is to be carried out. Figure 8 illustrates an example 
of a dialog box for selecting the characteristic properties 
of a policy. The specific example illustrated in the figure 
pertains to various metrics that can be measured during 
the execution of a program. The right panel 40 in the 
figure provides a list of measurable parameters for the 
network system. The user can select these parameters 
as desired, to be included in the properties of the policy. 
The selected metrics are illustrated in the left window 
42 of the dialog box. 

[0030] From the foregoing, therefore, it can be seen 
that the present invention provides an application mon- 
itoring system which is not intrusive, and therefore can 
be utilized in connection with any type of application pro- 
gram that is executed on a computer. Since the moni- 
toring functions are carried out at the site of the client 
application itself, rather than intermediate the client and 
a network server, a true measurement is obtained of the 
actual latencies that occur in the execution of a program. 
Furthermore, by utilizing a macro language that trans- 
lates communications between the application program 
and operating system into terms that are readily under- 
standable by a user, the ability to configure the monitor- 
ing system is greatly enhanced. 

[0031] With reference to Figure 4, it can be seen that 
the monitoring system of the present invention is com- 
prised of a number of components. In a practical imple- 
mentation of the invention, these components can be 
distributed in a variety of manners. When used on a 
stand-alone computer, of course, all of the components 
may reside on a single computer. However, it is also pos- 
sible to first define the transaction to be monitored with 
a configuration manager that is running on one compu- 
ter, and then distribute that transaction, and any asso- 
ciated policy, to agents on other stand-alone computers 
which do not contain the configuration manager them- 
selves. In a network environment, it is possible to have 
an agent running on each network node, as illustrated 
in the embodiment of Figure 1. However, such an ar- 
rangement is not necessary. Rather, the agents can be 
located at a central location, and from there instruct the 
central dispatcher, which might also be located at the 
central location or on the individual nodes, to initiate the 
monitoring procedures by establishing the watch func- 
tions in the memory space of the application programs 
to be monitored. Thus, as long as the various modules 
can communicate with each other as necessary, they 
can be located anywhere within the networked system. 
[0032] It will be appreciated by those of ordinary skill 
in the art that the application can be embodied in other 
specific forms. For example, although the disclosed em- 
bodiment of the invention has been described in the con- 
text of a computer which employs the Windows operat- 



ing system, the practical applications of the invention 
are not limited thereto. Rather, the invention can be em- 
ployed in any type of system in which it is possible to 
externally detect specific events that are associated with 

5 the execution of an application program. The presently 
disclosed embodiments are therefore considered in all 
respects to be illustrative, and not restrictive. The scope 
of the invention is indicated by the appended claims, 
rather than the foregoing description, and all changes 

*0 that come within the meaning and range of equivalents 
thereof are intended to be embraced therein. 



Claims 

15 

1 . A method for monitoring the response times of ap- 
plication programs running on a computer, compris- 
ing the steps of: 

observing communications between an appli- 
cation program (12) and an operating system 
program running on the computer; 
detecting the times at which predefined com- 
munications are exchanged between the appli- 
cation program (12) and the operating system 
program; 

determining the latency associated with an ap- 
plication response in accordance with the dif- 
ference in detected times; and 
storing the determined latency. 

2. The method of claim 1 wherein said predefined 
communications are selected by a user from a se- 
quence of communications that are exchanged be- 
tween the application program and the operating 
system program. 

3. The method of claim 2 wherein said sequence of 
communications is provided to the user by operat- 
ing the application program in a normal manner re- 
cording communications that are exchanged during 
such operation, terminating the recording of com- 
munications and displaying the recorded communi- 
cations upon termination of the recording process. 

An applications agent (14) for monitoring the re- 
sponse times of application programs running on a 
computer, comprising: 

means for observing communications between 
an application program (12) and an operating 
system program running on the computer; 
means for detecting the times at which said 
communications are exchanged between the 
application program (1 2) and the operating sys- 
tem program; 

means for calculating the latency associated 
with the difference in detected times; and 
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means for storing the calculated latency. Patentanspruche 



5. The agent of claim 4 further including a configura- 
tion manager for enabling a user to select prede- 
fined communications from a sequence of commu- 
nications that are exchanged between the applica- 
tion program and the operating system program, 
and wherein said detecting means detects the times 
at which said predefined communications occur 

6. The agent of claim 5 wherein said configuration 
manager includes means for recording commu nica- 
tions that are exchanged during the operation of the 
application program in a normal manner, means for 
terminating the recording of communications, 
means for displaying the recorded communications 
upon termination of the recording process, and 
means for enabling the user to designate selected 
ones of the displayed communications as said pre- 
defined communications. 

7. The agent of claim 6 further including means for 
translating communications exchanged between 
the application program and the operating system 
program into high-level language terms for display 
to the user. 

8. The agent of claim 7 wherein said translating means 
combines plural communications into a single high- 
level language term. 

9. A system for monitoring the response times of ap- 
plication programs (12) being executed on a com- 
puter, comprising: 

a configuration manager (30) for presenting to 
a user a sequential listing of detectable events 
which occur during the execution of an applica- 
tion program (1 2) including means for enabling 
the userto select individual ones of said events 
to define a transaction to be monitored; 
means for examining information exchanged 
between the application program (12) and an 
operating system running on the computer, to 
detect the occurrence of the events selected by 
the user; 

means for recording the times at which detect- 
ed events occur; and 

means for calculating and storing the elapsed 
time between the occurrence of selected 
events, to thereby provide a metric of applica- 
tion response time. 

10. The system of claim 9 wherein said configuration 
manager includes means for recording events 
which occur as the user issues commands during 
the execution of an application, and displaying said 
recorded events as said sequential listing. 



1. Verfahren zum Beobachten von Antwortzeiten von 
Anwendungsprogrammen, die auf einem Computer 

5 laufen, umfassend die Schritte: 

Beobachten von Benachrichtigungen zwischen 
einem Anwendungsprogramm (12) und einem 
Betriebssystemprogramm, die auf dem Com- 
10 puter laufen; 

Ermitteln von Zeiten, zu denen vorbestimmte 
Benachrichtigungen zwischen dem Anwen- 
dungsprogramm (12) und dem Betriebssy- 
15 stemprogramm ausgetauscht werden; 

Bestimmen einer Wartezeit, die mit einer An- 
wendungsantwort in Ubereinstimmung mit ei- 
ner Differenz in den ermittelten Zeiten verbun- 
20 den ist; und 

Speichern der ermittelten Wartezeit. 

2. Verfahren gemaB Anspruch 1 , wobei die vorbe- 
25 stimmten Benachrichtigungen durch einen Benut- 

zer aus einer Sequenz von Benachrichtigungen 
ausgewahlt werden, die zwischen dem Anwender- 
programm und dem Betriebssystemprogramm aus- 
getauscht werden. 

30 

3. Verfahren gemaf3 Anspruch 2, wobei die Sequenz 
von Benachrichtigungen dem Benutzer durch An- 
wendung des Anwendungsprogramms auf normale 
Art und Weise, Aufzeichnung von Benachrichtigun- 

35 gen, die wahrend einer solchen Anwendung ausge- 
tauscht werden, beenden der Aufzeichnung der Be- 
nachrichtigungen und Anzeigen der aufgezeichne- 
ten Benachrichtigungen nach Beendigung des Auf- 
zeichnungsvorgangs bereitgestellt wird. 

40 

4. Anwendungsagent (14) zum Beobachten der Ant- 
wortzeiten von Anwendungsprogrammen, die auf 
einem Computer laufen, umfassend: 

45 eine Einrichtung zum Beobachten der Benach- 

richtigungen zwischen einem Anwendungspro- 
gramm (12) und einem Betriebssystempro- 
gramm, die auf einem Computer laufen; 

50 eine Einrichtung zum Ermitteln der Zeiten, zu 

denen die Benachrichtigungen zwischen dem 
Anwendungsprogramm (12) und dem Betriebs- 
systemprogramm ausgetauscht werden; 

55 eine Einrichtung zum Errechnen einer Warte- 

zeit, die mit einer Differenz in den ermittelten 
Zeiten verbunden ist; und 
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eine Einrichtung zum Speichern der errechne- 
ten Wartezeit. 

5. Agent gemaB Anspruch 4, ferner umfassend einen 
Konfigurationsmanager, um es einem Benutzer zu 5 
ermoglichen, vorbestimmte Benachrichtigungen 
aus einer Sequenz von Benachrichtigungen, die 
zwischen dem Anwendungsprogramm und dem 
Betriebssystemprogramm ausgetauscht werden, 
auszuwahlen, und wobei die Ermittlungseinrich- 10 
tung die Zeiten, zu denen die vorbestimmten Be- 
nachrichtigungen stattfinden, ermittelt. 

6. Agent gemaB Anspruch 5, wobei der Konfigurati- 
onsmanager eine Einrichtung zum Aufzeichnen von 15 
Benachrichtigungen, die wahrend der Anwendung 
des Anwendungsprogramms auf normale Art und 
Weise ausgetauscht werden, eine Einrichtung zum 
Beenden der Aufzeichnung von Benachrichtigun- 
gen, eine Einrichtung zum Anzeigen der aufge- 20 
zeichneten Benachrichtigungen nach Beendigung 
des Aufzeichnungsvorgangs, und eine Einrichtung, 

die es dem Benutzer ermoglicht, ausgewahlte der 
angezeigten Benachrichtigungen als die vorbe- 
stimmten Benachrichtigungen zu kennzeichnen. 25 

7. Agent gemaG Anspruch 6, ferner umfassend eine 
Einrichtung zum Ubersetzen von Benachrichtigun- 
gen, die zwischen dem Anwendungsprogramm und 
dem Betriebssystemprogramm ausgetauscht wer- 30 
den, in Hochsprache, um sie dem Benutzer anzu- 
zeigen. 

8. Agent gemaft Anspruch 7, wobei die Ubersetzungs- 
einrichtung mehrere Benachrichtigungen zu einem 35 
einzelnen Hochsprachenausdruck kombiniert. 

9. System zum Beobachten der Antwortzeiten von An- 
wendungsprogrammen (1 2), die auf einem Compu- 
ter ausgefuhrt werden, umfassend: 40 

einen Konfigurationsmanager (30), um einem 
Benutzer eine sequentielie Auflistung von er- 
mittelbaren Ereignisse anzuzeigen. die sich 
wahrend der Ausfuhrung eines Anwendungs- 45 
programms (12) ereignen, umfassend eine Ein- 
richtung, die es dem Benutzer ermoglicht, indi- 
viduelle der Ereignisse auszuwahlen, um eine 
zu uberwachende Durchfuhrung zu definieren; 

50 

eine Einrichtung zum Untersuchen von Infor- 
mationen, die zwischen dem Anwendungspro- 
gramm (12) und einem Betriebssystem, die auf 
dem Computer laufen, ausgetauscht werden, 
um das Eintreten der von dem Benutzer aus- ss 
gewahlten Ereignisse zu ermitteln; 

eine Einrichtung zum Aufzeichnen der Zeiten, 



zu denen sich ermittelte Ereignisse ereignen; 
und 

eine Einrichtung zum Errechnen und Speichern 
der verstrichenen Zeit zwischen dem Eintreten 
von ausgewahlten Ereignissen, um dadurch ei- 
ne Metrik der Anwendungsantwortzeit bereit- 
zustellen. 

10. System gemaB Anspruch 9, wobei der Konfigurati- 
onsmanager eine Einrichtung zum Aufzeichnen von 
Ereignissen umfasst, die eintreten, wenn der Be- 
nutzer Befehle wahrend der Ausfuhrung einer An- 
wendung erteilt, und zum Anzeigen der aufgezeich- 
neten Ereignisse als die sequentielie Auflistung. 

Revendications 

1 . Procede pour le controle des temps de reponse de 
programmes d'application se deroulant dans un or- 
dinateur, comprenant les etapes suivantes : 

I'observation des communications entre un 
programme d'application (1 2) et un programme 
du systeme d'exploitation se deroulant dans 
I'ordinateur ; 

la detection des moments auxquels des com- 
munications predefinies sont echangees entre 
le programme d'application (12) et le program- 
me du systeme d'exploitation ; 
la determination de la latence associee a une 
reponse d'application selon la difference entre 
les moments detectes ; et 
le stockage de la latence determinee. 

2. Procede selon la revendication 1 , dans lequel les- 
dites communications predefinies sont selection- 
nees par un utilisateur a partir d'une sequence de 
communications qui sont echangees entre le pro- 
gramme d'application et le programme du systeme 
d'exploitation. 

3. Procede selon la revendication 2, dans lequel ladite 
sequence de communications est fournie a I'utilisa- 
teur en mettant en oeuvre le programme d'applica- 
tion de maniere normale, en enregistrant les com- 
munications qui sont echangees pendant cette mi- 
se en oeuvre, en mettant fin a I'enregistrement des 
communications et en affichant les communications 
enregistrees lorsqu'il est mis fin au procede d'enre- 
gistrement. 

4. Agent d'application (14) pour controler les temps de 
reponse de programmes d'application se deroulant 
dans un ordinateur, comprenant : 

des moyens pour observer des communica- 
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5. Agent selon la revendication 4, comprenant en 
outre un gestionnaire de configuration pour permet- 
tre a un utilisateur de selectionner des communica- 
tions predefines a partir d'une sequence de com- is 
munications qui sont echangees entre le program- 
me d'application et le programme du systeme d'ex- 
ploitation, et dans lequel lesdits moyens de detec- 
tion detectent les moments auxquels se produisent 
lesdites communications predefinies. 20 

6. Agent selon la revendication 5 } dans lequel ledit 
gestionnaire de configuration comprend des 
moyens pour enregistrer des communications qui 
sont echangees pendant la mise en oeuvre du pro- 25 
gramme d'application de maniere normale, des 
moyens pour mettre fin a Tenregistrement des com- 
munications, des moyens pour aff icher les commu- 
nications enregistrees lorsqu'il est mis fin au proce- 

de d'enregistrement, et des moyens pour permettre 30 
a I'utilisateur de designer certaines communica- 
tions affichees selectionnees comme communica- 
tions predefinies. 

7. Agent selon la revendication 6, comprenant en 35 
outre des moyens pour traduire des communica- 
tions echangees entre le programme d'application 

et le programme du systeme d'exploitation en ter- 
mes de langage evolue a des fins d'affichage pour 
I'utilisateur. 40 

8. Agent selon la revendication 7, dans lequel lesdits 
moyens de traduction combinent des communica- 
tions plurielles en un terme unique de langage evo- 
lue. 45 

9. Systeme de controle des temps de reponse de pro- 
grammes d'application (12) a mettre en oeuvre 
dans un ordinateur, comprenant : 

50 

un gestionnaire de configuration (30) pour pre- 
senter a un utilisateur un listage sequentiel 
d'evenements detectables qui se produisent 
pendant la mise en oeuvre d'un programme 
d'application (12) comprenant des moyens 55 
pour permettre a I'utilisateur de selectionner in- 
dividuellement certains desdits evenements 
pour definir une transaction a controler ; 



16 

des moyens pour examiner les informations 
echangees entre le programme d'application 
(12) et un programme du systeme d'exploita- 
tion se deroulant dans I'ordinateur, pour detec- 
ter la survenue des evenements selectionnes 
par I'utilisateur ; 

des moyens pour enregistrer les moments aux- 
quels se produisent les evenements detectes ; 
et 

des moyens pour calculer et stocker le temps 
ecoule entre la survenue des evenements se- 
lectionnes, pour fournir ainsi une mesure du 
temps de reponse d'application. 

10. Systeme selon la revendication 9, dans lequel ledit 
gestionnaire de configuration comprend des 
moyens pour enregistrer des evenements qui se 
produisent lorsque I'utilisateur lance des ordres au 
cours de Pexecution d'une application, et pour affi- 
cher lesdits evenements enregistres en tant que dit 
listage sequentiel. 
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tions entre un programme d'application (12) et 
un programme du systeme d'exploitation se de- 
roulant dans I'ordinateur ; 
des moyens pour detecter les moments aux- 
quels lesdites communications sont echan- 5 
gees entre le programme d'application (12) et 
le programme du systeme d'exploitation ; 
des moyens pour calculer la latence associee 
a la difference entre les moments detectes ; et 
des moyens pour stocker la latence calculee. 10 
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